When people in security speak of Gates's products, they sneer. It's a fact: Microsoft has never been a particularly secure platform, but then, these products have historically not needed to be secure. Nonetheless, times have changed; now there is a need. But if programmers at Microsoft take the next five years to hammer out some decent security schemes, they would be on par with the amount of time it took the UNIX community to do the same.
NOTE: On the other hand, Gates's assertion in The Road Ahead that we should all document our lives strikes me as a bit Orwellian. In that book, Gates suggests that all good computing citizens should store a complete record of their lives on computer (we should record all movements, purchases, appointments, and so forth). This recorded material, he writes, could serve as an alibi in the event such a citizen is accused of a crime. But if this documented life becomes an accepted alibi, what happens to those who do not maintain such records? In short, Gates is profoundly influencing the social construct of this nation. His work may well result in a two-class society. Gates is a brilliant man who has contributed much. Nonetheless, whether he is a true friend to humankind remains to be seen.
Microsoft products should not be subjected to the same scrutiny as UNIX products because they are in a different class. Despite this fact, many security specialists ridicule Microsoft products. They subject such products to rigorous tests, knowing that the products cannot pass. Then they parade the negative results across the Net, "proving" that Microsoft's security is weak and lackluster. This is irresponsible and creates a good deal of public unrest.
Security specialists should lament, not rejoice, when they find a hole in a Microsoft product. After all, such a hole simply represents one more hole in the Internet. Microsoft products should receive as much attention and respect as any other product. Moreover, security folks should educate, not ridicule, the cult following of Microsoft because that is the right thing to do.
NOTE: Microsoft's Windows NT uses a very good security model and is considered at least minimally safe. Nevertheless, although NT's security model is good, it does not mean that NT is secure in the same way that many versions of UNIX are secure.Many Microsoft advocates point out that the NSA has granted Windows NT a C2 security rating on the Evaluated Products List. This, they contend, is evidence that NT is secure. Not true. First, C2 is the very lowest security rating on the EPL. Moreover, NT's C2 rating is valid only on certain hardware (Compaq Proliant 2000 and 4000 Pentium and the DECpc AXP/150 Alpha). Furthermore, NT's C2 certification assumes that a non-networked, standalone workstation is being used. Thus, the NSA has effectively suggested that NT is minimally secure, as long as it runs on certain hardware, has no network connectivity, and is installed only as proscribed by the evaluation process. True, it was a great step forward for Microsoft's marketing department to obtain any rating on the EPL at all. Because most users have no idea what the EPL is, the rating sounds very impressive ("The National Security Agency says it's secure!"). In reality, however, the rating is not spectacular and is no guarantee of the security of NT.
This ease of use comes with a cost. For example, consider the swapping scheme in Microsoft Windows 3.11. Swap files and disk caches are devices that greatly enhance overall performance (they can compensate for sparse RAM resources). When a large swap is present, certain elements of a program need not be loaded into memory again. This results in increased speed and functionality. Unfortunately, it also results in poor security.
Any type of swapped memory system is insecure because traces of data are left within that swap file or swap area. (A good example is the use of encryption like PGP. When done through the Windows environment, the passphrase is written into the swap file and is therefore retrievable.)
Throughout this chapter, you will see how user friendliness has inhibited the development of a truly secure Microsoft operating system. (NT is excluded from this analysis and will be discussed at the end of the chapter. NT has advanced security features; these were responsible for Microsoft getting its first product onto the Evaluated Products List.)
Indeed, this is the greatest challenge facing Microsoft today. It must find a way to reconcile user friendliness with strong security. Until it does, Microsoft has no hope of seizing control of the Internet.
You may wonder why I would even bother to treat DOS security issues here. After all, the number of DOS-based machines connected to the Internet is limited. On closer examination, however, the relevance of DOS becomes more apparent. For example, it has become common for legacy Novell networks to be strung to the Internet. Many of these older networks (running 3.x or earlier) also run DOS-based applications. Here are just a few old favorites that you would be likely to find out there:
I will not exhaustively cover DOS, but there are a few issues I need to mention. As you might expect, many of these issues relate to physical or local security of DOS machines. If your network is devoid of any DOS machines, feel free to skip this portion of the chapter.
The next series of points are well known to users who are required to use IBM-compatible computers in their occupation. Much of this is therefore old hat, but I will run through it nevertheless. The rush to the Internet has prompted many people who never before had computers to get them. This section may therefore be helpful to some.
For a user who needs access to the machine (and who has never been granted such access), the solution is to remove, short out, or otherwise disable the CMOS battery on the main board (see Figure 16.1).
NOTE: The CMOS password function on an IBM compatible is used to protect the workstation from unauthorized users gaining control at the console. The CMOS password option (if set) results in a password prompt issued immediately at boot time. Indeed, when the CMOS password function is enabled, the boot is arrested until the user supplies the correct password.
FIGURE 16.1.
Physically disabling the CMOS password on an AT IBM compatible.
Your network workstations can easily be compromised in this manner. However, this is more likely done by someone who is attempting to steal the machine, as opposed to trying to breach security. Internal employees would use a different method. Because your own employees have some level of access on the system, they can pose a serious security threat. Even if they do not disassemble the machine, there are ways for internal, trusted folks to bypass that CMOS password. And although this is a commonly known fact among hackers and crackers, the average LAN supervisor may not be so aware.
I have seen offices, for example, where only the Novell administrator knew the CMOS passwords. The procedure was almost comical. The administrator came in early each morning and enabled all the workstations. At the end of the day, those workstations were shut down and the CMOS password would be active. The administrator assumed (wrongly) that in this manner, the network was safe from internal theft or tampering. This assumption was based largely on the premise that no one in the office knew the CMOS passwords but the administrator.
In fact, there are a number of CMOS password catchers on the market. These utilities capture a CMOS password either while the user is already logged in or during boot. Up to this point, we have not yet booted the machine; we are simply looking to get inside. These utilities and techniques will allow us to do so:
The technique discussed in Figure 16.2 is quite effective. The Alt+255 character is an extended ASCII character and therefore is invisible at a prompt. In Windows, it appears as a small, accented squiggle and is usually missed unless you are looking for it. Kids use this technique to hide games and racy photographs on their home and school machines.
FIGURE 16.2.
A directory gets hidden on the disk.
A number of key-capture utilities (or keystroke recorders) are available for DOS, including the following.
TIP: Hidden files are generally created using the attrib command or by the key-capture utility itself (in other words, the programmer has included this feature in the software).
One of the more extraordinary features of Playback is the way it handles the timing of keystrokes. Everything is based on exactly the same tempo of the keystrokes recorded. Say, for example, that the session recorded a login procedure. Many login procedures require a waiting period between the moment the user enters his login ID and the point at which he enters his password (this waiting period sometimes relates to a buffer issue and sometimes simply involves a slow file server). In any event, Playback plays back the keystrokes precisely as they are recorded. Therefore, it is a suitable tool for simulating a real session with some remote or even local login program. Based on these amenities, Playback became a favorite among crackers. It is located here:
At any rate, enough about techniques for cracking DOS. For a moment, I'd like to concentrate on preventing crackers from cracking a DOS box. There are many tools on the Internet designed expressly for this purpose and a majority are free for non-commercial use.
Clearly, the author of SFS wanted to make a serious contribution to DOS security. Compliance with the Federal Information Processing Standard (FIPS) and several other key standards are built into the program. Its compatibility with a host of disk-caching and memory-management programs makes the program all the more mind boggling. Finally, the documentation on this utility is superb. See the following:
Also be aware that many programming tools are available to circumvent your security. Certain distributions of C++, for example, contain programs that allow MS-DOS users to monitor system processes. These tools will also monitor network activity. Such monitoring tools are not restricted to programming applications, either.
One such application is Pcwatch. This program is designed expressly to examine the behavior of EXE files as they execute. Using this program, a cracker can accurately determine the elements of a program and where its vulnerabilities might lie (for example, where disk access occurs within the program, where memory swaps are performed, and within what address registers these events occur). It is a common utility employed by crackers when they need to crack a DOS file and is available here:
For specific network problems, refer to the chapter that addresses your operating system (Novell, UNIX, AS/400, and so forth). At this stage, I want to concentrate more on Windows-based security issues. Thus, here are some sites at which you can acquire security tools for the DOS environment:Briefly, I want to address the encryption routine and general environment behind the PWL file. First, the process uses two different functions: one to encrypt and store the password, another to retrieve it. Those are, respectively:
NOTE: In certain instances (when, for example, the cracker is seeking to gain access to a server), deletion will not do the trick. However, deleting one password allows the cracker to at least reach the local workstation, at which point he can crack other passwords.
Likewise, you may be able to force the cached password into the swap file. Reportedly, this technique reveals the password. (Nonetheless, this is a cumbersome and wasteful method; there are other, easier ways to do it.)
But again, unless the cracker is seeking access to a Windows NT server via a Windows for Workgroups box, this is academic. In most cases, the password files can simply be deleted. Because there is no default file access control (or restrictions) in Window for Workgroups, the PWL files do not stand a chance.
TIP: One method is where multiple passwords are added to the password database at high speed. You could technically use a utility similar to Claymore to do this. Using this technique, you fill the available space for passwords (255 of them, actually). This causes an overflow, and the routine then discards older passwords.
Windows for Workgroups, in its out-of-the-box state, provides no protection for those PWL files. Using a utility such as PAC.exe (or Ledbetter's find.exe), you can go to a prompt on a Windows for Workgroups workstation and disable all passwords on the network with a single command line. The process would take no more than two to three seconds. The command would be
NOTE: This is vastly different from UNIX or even Windows NT in real NTFS mode, where certain files are protected from read, write, or execute calls from unauthorized users. For example, in UNIX, the file /etc/passwd may indeed be readable (though, the system administrator ought to be using shadowing). However, no one without root privileges can access or write to that file.
pac /I /s *.pwl /kor
find *.pwl -vHaving executed these commands, the network is yours for the asking. This problem has been carried into the Windows 95 distribution. As explained on the Tip of the Month page at Ronster's Compendium:
This problem was not heavily publicized because Windows security was not an issue relevant to the Internet. However, almost immediately after Windows 95 (with rich, new Internet functionality) was released, the issue appeared in national magazines. In fact, many news stories concentrated not only on Microsoft's failure to protect such files, but also on the weak password scheme employed. As Eamonn Sullivan noted in his article "Win 95 Password Caching Flawed" (published in PC Week, December 8, 1995):
Cross Reference: Check out Ronster's Compendium's Tip of the Month page at http://199.44.114.223/rharri/tips.htm.
Reportedly, the way to password-protect a Windows 95 workstation is to set the properties so that password caching is disabled and to enable user customization of desktop preferences. The process takes no time at all:
2. If the Primary Network Logon option is not already set
to Windows Logon, you should set it to this option (see Figure 16.3).
2. Turn it back on and allow it to go through the initial
boot phase (that is, let the machine continue until it recognizes the drives
and until the Windows 95 screen comes up).
3. While the Windows 95 screen is still visible, the cracker executes a warm reboot procedure (this must occur while Windows 95 is attempting to load the initial system and drivers).
4. When the machine reboots, it will not load Windows 95. Instead, it will display a screen that offers to start the machine in several different modes, including safe mode and command-line mode.
5. The cracker chooses safe mode and proceeds to the Registry editor (by executing regedit). Once in the Registry editor, the cracker can do anything he likes (including disabling the options you set in the procedure outlined previously).
Many Microsoft security models are fragile. Consider Microsoft Access, the standard package for building business databases. Access uses a language called Access Basic. It is an extremely powerful package, often used to create multiuser databases. The newer versions of Access are incredibly fluid in the manipulation of data.
TIP: One excellent way to bypass the password security on networked boxes, particularly security schemes set with the Policy editor, is to simply pull the plug (remove the Ethernet card temporarily or unplug it from the machine). When Windows reboots, you will encounter errors, and you may be forced to go into safe mode (much depends on whether you are using third-party drivers on the box). In any event, in safe mode or normal mode, you can proceed to kill all the password protection.
Access performs authentication based on an internal security identifier (SID). This SID is derived from running the username and the personal identifier (PID) through an algorithm (these variables are used as the keys). The extraordinary thing is that if, in the creation of a new account, a cracker issues the same username and PID as the target, the resulting SID will be identical. Why didn't techs at Microsoft base this process on using the time and as a random number generator? This at least would create a digital value that would be reasonably unusual. In any event, this is academic. All legacy databases created in Microsoft Access 1.0 are vulnerable to another attack that is so simple, I will not print it here. Many businesses rely on such legacy databases, and I do not see how revealing that method will contribute to security. The problem has never been fixed by Microsoft and never will be. However, programmers are well aware of this flaw.
No doubt about it. Out-of-the-box security for Windows 95 sucks. What can be done about it? Well, many imaginative software authors have been put to the task. Some of their innovations are...well...interesting.
NOTE: Hints about the flaw: The "unique" SID created at setup for the Admins is written to disk 1 of the distribution. Also, anyone with another version of SYSTEM.MDA can access restricted files. Lastly, and perhaps most importantly, the SID of any user can be read and manually altered, allowing any user to inherit the privileges of any user. Did you create any databases while having Admin rights? If so, anyone can completely seize control of your Access database.
Cross Reference: If you are interested in this flaw, check out ftp://ftp.zcu.cz/mirrors/winsite/win3/misc/acc-sec.zip for more information.
NOTE: It is interesting to note that in the retail version of Windows 95, very few instances of the word security occur in the help files. Indeed, these references refer to whether the software on your machine is legal. Microsoft appears to have little interest in the security of 95, except in terms of whether you have stolen it from them. This is in complete contrast to Windows NT.
Although it is an interesting proposed solution to the problem, be assured that given 10 minutes alone with a machine so configured, the talented cracker could bypass the entire authentication procedure. Thus, this technology is most useful in offices or other places where such access is unlikely to occur (or where individuals are forbidden to turn off or reboot machines). CyberWatch can be found here:
FIGURE 16.6.
The WinSafe drive protection properties settings.
Of particular interest is that WinSafe protects network drives. Users can sample the application by checking out the available shareware application.
WinSafe is available here:
WARNING: The documentation suggests that using the Policy editor to set the REAL Mode DOS settings could potentially conflict with WinSafe.
As you might expect, pranksters on the Net have found innovative, new uses for the WordBasic language. One of those uses is to create malicious macros, or macro viruses. These can be gotten from the Internet. They will infect your normal.dot, thereby altering (and perhaps severely retarding) your default document environment.
The most well known of these macro viruses is called Concept. Concept infects not only the normal.dot file but any DOC file it can access. Reportedly, after the first infection (the first instance that Word is opened after initial infection), every document saved thereafter will also be infected. It also reportedly works on any platform that runs Word and has been found on at least one commercial CD-ROM distribution, as noted by Graham Cluley in his article "Another Instance of Concept Macro Virus in Microsoft CD ROM":
At one point, a fix was issued for this. It was called scanprot.dot, and its primary purpose was to scan for the Concept virus. However, this tool was somehow confused in the public's eyes as a utility that could identify all macro viruses. Microsoft finally set the record straight. Since that time, many Word macro viruses have cropped up. Here are just a few:
Cross Reference: There is a reliable military site where you can acquire tools to determine whether your machine has been infected. That site is located at http://www-yktn.nosc.mil/Desktop_Support/winword/concept_virus.htp.The main tool for identifying the virus is a Word document macro. You can get it at http://ded-2-nt.nosc.mil/~pub/MSOffice/Winword/virus/WVFIX.DOC.
NOTE: It is reported that the Microsoft Word Wizard will not operate if you disable automatic macro execution. If you are a frequent user of wizards, you may have to make some sacrifices.
Cross Reference: You can find the authoritative sources for information on Word macro viruses at these locations:http://www.datafellows.com/macro/faq.html
http://gasp.berkeley.edu/virus/wordmacro.html
Unfortunately, early versions of Microsoft's FrontPage Web server were distributed with a Practical Extraction and Report Language interpreter (PERL.exe). If this is placed in the /cgi-bin/ directory, a massive security hole develops. It allows any remote user to execute arbitrary commands on your local machine.
I would not have mentioned this here, except that older demo versions of FrontPage may surface in places other than the Microsoft home page. This is not unreasonable. There are still early versions of Microsoft Internet Explorer circulating on demo CD-ROMs from magazines and such.
Cross Reference: For more information about this hole, check out Microsoft's Web site at http://www.microsoft.com.
Cross Reference: The previous paragraph is excerpted from ORA's WebSite security alert at http://website.ora.com/devcorner/secalert1.html. 03/96. Also, there is a sample CGI application, win-c-sample.exe, that shipped with version 1.0. This application is vulnerable to a buffer-overflow attack.
Cross Reference: Because no one seems to give credit to the individual who discovered the buffer overflow hole, it seems right that I do so. To the best of my knowledge, this hole was identified by a hacker going by the handle Solar Designer.
Cross Reference: For more information about holes in O'Reilly's WebSite Server, check out http://website.ora.com/justfacts/facts.html.
MISF purportedly will integrate a series of technologies into Microsoft products, thus making them secure for Internet use. I briefly discussed one of these technologies earlier in this book: the certificate signature scheme for ActiveX controls (or in fact, any code that you specify). It revolves around a technology called Authenticode, a system whereby developers can digitally sign their applications. It consists of a series of programs. By using these, the software developer ultimately earns a Software Publisher's Certificate (SPC), which is used to sign the application. Interestingly, you can sign the application in different ways: as a provider, a commercial software developer, or an individual.
This system works effectively only if the signing party is honest. There is no guarantee that signed code will be safe. Thus, the system actually subjects honest, upright programmers to additional hassle (nonetheless, I am confident this system will become exceedingly popular among developers of Microsoft products). However, there is a darker side to this.
The greatest percentage of falsely signed code (code that is malicious and has been signed as safe) will likely come from individuals. I suspect that many virus developers will adopt this system, because it represents a chance to deposit their code into a largely unwary community (if a control is signed, the average person will probably download it). Because of this, widespread use of such signatures will hurt the little guy. Here is why.
Because the technology is new, there have been no instances of signed malicious code. However, as time passes and signed malicious code surfaces, the average user will be less likely to download software from new companies or lone software developers (certainly, the public will be much less likely to download unsigned code). Moreover, this system may cause even further alienation of foreign developers (more than once, the sense of alienation experienced by foreign developers has been blamed for the high number of viruses believed to have originated on foreign soil). Finally, there is something a bit ominous about having to provide a public key to engage in commerce as a software developer. What happens to the remaining folks who refuse to comply with the program? If they suffer in the market for lack of compliance, antitrust issues may develop (particularly if this becomes the only accepted method of okaying software).
In any event, Microsoft is at least going in the right direction. Public and private key encryption schemes are among the most secure today. Moreover, the new technologies presented within Microsoft's white paper about MISF suggest that Microsoft is quite serious about solutions in Internet security.
NOTE: In February 1997, members of the famed German hacker group known as the Chaos Computer Club used a signed application to demonstrate the weakness of the Microsoft platform and of application signing generally. On national television, they used this application to gain unauthorized access to a personal computer, start an instance of Quicken, connect to the victim's online bank account, and transfer money from the victim's account to another. This was a crushing blow to the signing model. I explain this in further detail in Chapter 30, "Language, Extensions, and Security."
NOTE: For basic networking, Novell NetWare has always been a fairly secure platform and has long supported access control. This does not mean NetWare cannot be cracked (see Chapter 18, "Novell"). However, control over file and time access has been an integral part of the Novell NetWare security model.
In DAC, there are different levels of control. For example, some operating systems or utilities offer only moderate control (perhaps one system might allow an administrator to block user access to directories or partitions). This type of control is not really suitable in large networks, where one or more directories may hold applications or resources that other programs need in order to execute. The Microsoft Windows platform is a good example of this. Most applications written for Windows sport multiple file dependencies. That means the application may need files from different parts of the system in order to function correctly.
The degree to which a DAC system can control file and directory access is referred to in security vernacular as granularity. Granularity is, quite simply, an index for measuring just how detailed that access control can be. If, for example, you can choose a directory and restrict access to five files within it to a particular group but also allow all users to access the remaining ten files in that directory, then you are dealing with fairly advanced granularity.
NOTE: If you have ever had a bad installation of a product intended to run in Windows, you know something about this. The application so installed will, when executed, forward a series of error messages, requesting files that it cannot locate. In most cases, unless the program locates those files, it will not run (or if it does, it will probably GPF or exit on error).
DAC is a technology that has trickled down from defense sources. In defense environments, administrators must be assured that only authorized personnel can access sensitive data.
DAC is based on common sense: If crackers do not have access to the files, they cannot crack the machine. Setting proper file permissions is the first phase of securing a Windows NT machine. However, in order to do it, you must enable the NTFS option at time of installation (alas, we must begin at the beginning).
Cross Reference: For a greater understanding about DAC, how it evolved, and what it means in terms of national computer security, you should read DoD 5200.28-STD, the Department of Defense Trusted Computer System Evaluation Criteria (this publication is more commonly referred to as the Orange Book). It can be found at http://www.v-one.com/newpages/obook.html.
NTFS is the enhanced file system included with the NT distribution. At installation, you are confronted with the option of installing a FAT file system or an NTFS file system. There is a sharp difference between the two. The FAT file system will grant you some security, for you can control user access and authentication. However, for severely granular control (control over each file and directory), you must convert the partition to NTFS. This is a point often missed by new system administrators.
As noted, the NTFS security model is not perfect. For example, it is known that in certain distributions (such as 3.51), users without privileges can delete files. Microsoft has acknowledged this fact in an advisory. It involves any instance in which a user creates a file and removes all permissions from it. Technically, that file should still be untouchable to anyone but its author. However, for reasons not yet determined, the unauthorized user can delete the file. As noted in a Microsoft technical article titled "Users Without Permissions Can Delete Files at Server,":
CAUTION: Converting the partition to NTFS provides compressive security but is not infallible. For example, a kid sporting a Linux boot disk (only certain versions of Linux) can effectively bypass all of the file restrictions imposed by the NTFS DAC method (I am quite sure that CS lab administrators will be pleased to hear this). Also, this is not the only type of boot disk that will perform this task. When a file called NTFSDOS.EXE, which is being circulated on the Internet, is placed on a DOS or Windows 95 boot disk, it allows a cracker to bypass all file restrictions. Until this is fixed, NT will never get a higher rating than C2 on the EPL. Only those who rely solely upon Microsoft press releases and bug fixes actually believe that out-of-the-box NT is secure.
In general, however, Windows NT DAC is quite good. It resembles in some ways the DAC scheme implemented under UNIX-based operating systems. At the heart of this process are the theories of file ownership and privileges. Thus, whoever creates a file owns that file. The degree to which other users may examine that file depends on what restrictions were set forth by the administrator.
Note that this does not close every local security hole and that many processes require files to have more liberal ownership than you might like. For example, consider Common Gateway Interface (CGI) scripts used to provide functionality to Web pages (these scripts are commonly used to generate quotes, process mail requests, and access databases). Such scripts must have file permissions that, at the very least, allow outsiders (through the Web server) to access them. Thus, the Web server must have at least partial ownership or privileges to execute these files.
So on your drives, you might have files that can be read by some, written by others, and executed by still others. This presents the very first problem with regard to DAC: it is complicated. For example, on networks where permissions are set not only on files and directories, but also on partitions or network drives, the system administrator can become overwhelmed with the possibilities. For this reason, NT system administrators must be every bit as knowledgeable (and as obsessive) as UNIX system administrators.
However, this is where the process of NT security starts. Before setting up a network, you must first determine who will need access to what. Some utilities are available to make the process easier.
This tool, created by Somar Software, is available at the following location:
The primary use for the program is to identify outdated objects or links within the Registry. These may be sources of security problems. This utility makes the search quick and convenient. The command line options afford the administrator an enormous amount of control over how the search is performed.
NT RegFind can be found online at
A demo version of this product is available at the following URL:
Before I get into strictly Internet-related NT security, I should say something about suspicious internal activity. It is likely that most attacks will originate from people on your own network (those attacks might just be employees fooling around, or they could derive from a mole for a competitor). To keep an eye on internal security, there are a few utilities you should know about.
NOTE: You must have advanced system privileges to run this application. The company that provides this software also performs password recovery services for businesses.
More information about IP-Watcher can be found online at
Cross Reference: The previous paragraph, excerpted from IP-Watcher Risks: Quick Overview, can be found online at http://www.engarde.com/software/ipwatcher/risks/overview.html.
GET ../..If you are vulnerable, your Web server will die and the machine will likely crash. Note that this bug is not evident in IIS 3.0. To fix the problem, obtain Service Pack 1a and Service Pack 2 from Microsoft.
Port 80 is the standard port on which Web servers are normally run. To reach this port by Telnet, you must specify both the address of the targeted server and the port (see Figure 16.7).
FIGURE 16.7.
Initiating a Telnet session to port 80 in Windows 95.
Meanwhile, that is not the only denial-of-service attack that can be implemented against Windows NT. Other attacks involve simply initiating a Telnet session to certain ports. Naturally, these ports have to open for the attacks to be successful. However, I would bet that a significant percentage of system administrators fail to examine the higher range ports. For example, initiate a Telnet connection to port 135 or port 1031. After you receive a confirmation that you have contacted the port, send several lines of text and disconnect. If the machine has a vulnerable distribution, the CPU of the target will immediately jump to extreme utilization (this will incapacitate the target). One Perl script being circulated across the Internet automates this process.
For the moment, it is likely that such holes will continue to surface. Therefore, system administrators should enable not only packet filtering, but also deep logging. If your network is victimized by some malicious character in the void, you will want his IP address.
NOTE: Microsoft has issued a patch for the problem related to port 135, but as of this writing there is no fix for port 1031. In fact, reports as recent as February 2, 1997, reveal that many ports are vulnerable to this attack.
NT Server version 4.0 is also reportedly vulnerable to a denial of DNS (domain name service) attack. Crackers can implement this by sending a response packet to the DNS server of an NT DNS server. The server receives the response packet, cannot process the transaction, and promptly crashes. Some sources indicate that Service Pack 3 will provide a fix.
There is also reportedly a bug that allows a remote user to gather important information about an NT box. This is done using the NBTSTAT command. The user issues an NBTSTAT--a query on the targeted host to get that host's name. The resulting name is placed in the lmhosts file. Subsequent network queries about the host will reveal shared out directories, a list of users, and other vital network information (the information gathered is roughly equivalent to that in UNIX when utilizing the showmount command and rusers).
For purposes of brevity, I will not launch into an exhaustive review of SMB. Basically, it is a network file-sharing protocol based on the client/server model. It is used to share files, directories, printers, and serial communication links. It can be run over (and in conjunction with) a number of other protocols, including
Cross Reference: Hard-core documentation on the internal specifications of SMB can be found at ftp://ftp.microsoft.com/developr/drg/CIFS/. This site is the main distribution point for Microsoft's documentation on SMB. The file of greatest importance for users wanting to learn the advanced technologies behind SMB is called SMB-CORE.PS. This file is in PostScript, and you will require a PostScript reader to view it.
A cracker using an SMB client package (SAMBA) sends the following message to the SMB server on the remote NT box:
DIR..\This crashes the target. Microsoft acknowledged this problem and hastily distributed a fix, which you should obtain if you are running 3.5 or 3.51.
The second hole is more complex and is not likely to be penetrated by the average cracker. It is reported that shared-out directories can be mounted from a remote location using the SAMBA client. This is a complex attack, involving advanced methods of spoofing. As a July 1996 technical paper explains:
Cross Reference: I recommend reading the Microsoft advisory on this problem; this advisory can be found online at http://www.microsoft.com/kb/articles/q140/8/18.htm.
Such an attack is extremely complex. Few crackers possess the knowledge and expertise to implement such a technique.
Cross Reference: The previous paragraph is excerpted from an RFC titled "Common Internet File System Protocol (CIFS/1.0)," by I. Heizer, P. Leach, and D. Perry. It can be found online at ftp://ietf.cnri.reston.va.us/internet-drafts/draft-heizer-cifs-v1-spec-00.txt.
Windows NT Administration: Single Systems to Heterogeneous Networks. Marshall Brain and Shay Woodard. Prentice Hall. ISBN: 0-13-176694-5. 1994.
Inside the Windows NT File System. Helen Custer. Microsoft Press. ISBN: 1-55615-660-X. 1994.
NT Server: Management and Control. Kenneth L. Spencer. Prentice Hall, October 1995. ISBN: 0-13-107046-0.
Microsoft Windows NT TCP-IP Guide. Microsoft Press. ISBN: 1-55615-601-4. 1993.
Managing Windows NT Server 4. Howard Hilliker. New Riders. ISBN: 1-56205-576-3.
Windows NT 4 Electronic Resource Kit. Sams.net. ISBN: 0-67231-032-5.
Inside Windows NT Server 4. Drew Heywood. New Riders. ISBN: 1-56205-649-2.
Peter Norton's Complete Guide to Windows NT 4.0 Workstation. Peter Norton and John Paul Mueller. Sams Publishing. ISBN: 0-67230-901-7.
"A Guide to Understanding Discretionary Access Control in Trusted Systems." Technical Report NCSC-TG-003. National Computer Security Center. 1987.
"Authentication and Discretionary Access Control." Paul A. Karger. Computers & Security, Number 5, pp. 314-324, 1986.
"Extended Discretionary Access Controls." S. T. Vinter. SympSecPr, pp. 39-49, IEEECSP, April 1988.
"Beyond the Pale of MAC and DAC--Defining New Forms of Access Control."Catherine J. McCollum, Judith R. Messing, and LouAnna Notargiacomo. SympSecPr, Research in Security and Privacy, pp. 190-200, IEEECSP, May 1990.
© Copyright, Macmillan Computer Publishing. All rights reserved.